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Armstar  Background  and  Objectives 

The  Armstar  model  is  founded  on  a  belief  that  health  status,  outcomes,  and  costs  will  be 
improved  through  better  access  to  information  and  that  access  to  information  can  be 
improved  with  innovative  uses  of  information  technology. 

The  rural  community,  with  its  long  distance  from  and  limited  access  to  healthcare 
resources,  presents  many  healthcare  delivery  challenges  that  drive  up  the  cost  of 
providing  quality  services.  This  mirrors  many  of  the  healthcare  delivery  challenges 
found  in  the  Navy  deployed  forces  environment.  With  ACMH,  a  non-profit  community 
hospital  located  in  central  Armstrong  County  in  Western  Pennsylvania,  as  the  hub,  the 
rural  community  is  ideal  as  a  test  bed  for  the  development  of  an  affordable 
civihan/military  community  health  information  communication  system  in  its  more 
manageable  number  of  linkages  than  might  be  found  in  more  complex  urban 
environments.  Information  technology  which  can  be  successfully  employed  in  the  rural 
healthcare  delivery  system  to  overcome  resource  shortages  and  improve  collaboration 
among  providers  can  be  successfully  used  to  improve  the  quality  and  reduce  the  cost  of 
healthcare  provided  to  deployed  armed  forces  units  and  their  dependents.  The  Armstar 
model  positions  the  rural  community  hospital  as  a  collaboration  hub  that  electronically 
connects  smaller  healthcare  providers  to  other  networks  and  enables  information  sharing 
and  establishes  the  utility  of  commercial  off  the  shelf  technology  (COTS)  to  provide  low- 
cost  interfaces  to  clinical  users. 

The  Armstar  project  began  in  1996  by  ACMH  and  independent  practitioners,  and  our  first 
accomplishment  was  to  develop  a  secure  and  flexible  network  infrastructure  extending  to 
the  far  reaches  of  Armstrong  County  for  the  purpose  of  bringing  healthcare  information 
to  authorized  providers.  Our  collective  goal  has  been  to  use  tele-health  technology  and 
healthcare  informatics  to  overcome  many  barriers  to  access  and  increase  the  quantity  and 
quality  of  healthcare  services  rural  clinicians  are  able  to  provide. 

The  project  has  been  designed  as  four  major  phases  to  insure  that  the  technology  acquired 
and  developed  in  each  phase  will  survive  regardless  of  the  funding  of  any  future  phase. 

Phase  I  -  the  infrastructure 

The  first  phase  of  the  project  was  to  develop  a  repository  of  hospital  information  and 
make  it  available  to  independent  practitioners  serving  the  same  population  of  patients. 

The  repository  contains  test  results,  consultative  reports,  history  and  physical  reports, 
operative  reports,  medication  lists,  allergies  and  diagnoses.  Fire  walls  and  secure 
identification  methodologies  have  been  implemented  to  assure  that  only  authorized  users 
have  access  to  the  data  while  simplifying  access  by  the  user-friendliness  of  a  web 
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browser.  ACMH  has  recruited  experienced  network  engineers  and  healthcare  informatics 
personnel  to  manage  and  support  this  system  for  the  benefit  of  the  patients  and  providers 
in  Armstrong  County. 

Phase  II  -  the  integration  of  healthcare  information 

The  second  phase  of  the  project,  the  subject  of  this  report,  has  focused  on  the 
development  of  a  common  portal  to  integrate  access  to  the  hospital  repository,  radiology 
images  and  care-critical  primary  care  information.  A  picture  archival  and  retrieval 
system  (PACS)  has  been  implemented  and  integrated  with  an  evolving  electronic  medical 
record.  Software  has  been  developed  to  facilitate  the  capture  of  care-critical  information 
from  legacy  (paper)  medical  records.  An  integration  engine  has  been  programmed  to 
take  advantage  of  all  ANSI  and  HL7  standards  to  facilitate  the  transmission  of  data  from 
one  system  to  another.  The  infrastructure  is  sufficiently  developed  to  support  research 
regarding  user  interfaces  and  their  impact  on  care  delivery. 

Phase  II  -  add-on  -  to  begin  February  2004. 

In  this  add-on  phase,  requirements  identified  in  Phase  II  will  be  folded  into  the  model  and 
improve  our  ability  to  conduct  further  field  tests.  The  activities  planned  are:  1)  the 
development  and  deployment  of  patient  access  cards  that  contain  links  to  care-critical 
information;  2)  completion  of  Phase  II  field  testing;  3)  the  development  of  an  information 
link  to  remote  trauma  centers  for  care  critical  information  from  the  ACMH  repository  and 
the  records  of  its  medical  staff;  4)  the  expansion  of  PACS  to  include  Computed 
Radiography  CR  capability  for  non-digital  radiology  modalities;  5)  completion  of  the 
network  to  include  information  technology  aimed  at  reducing  the  potential  for  medical 
errors. 

Phase  HI  -  portability  and  technology  transfer  -10/1/2004  - 12/31/2005 

To  validate  the  broad  applicability  and  portability  of  the  Armstar  technology  and  to 
assess  the  magnitude  of  potential  cost  savings,  we  will  implement  the  Armstar  model  of 
connectivity  in  another  Western  Pennsylvania  community,  conduct  a  needs  assessment 
for  integration  with  major  healthcare  networks  and  implement  the  trauma  link  developed 
in  the  Phase  II  add-on. 

Phase  IV  -  integration  with  major  healthcare  networks  -  1/1/2005  -  9/30/2006 

In  this  phase  we  plan  to  connect  the  two  Armstar  networks  with  other  major  public  and 
private  healthcare  networks. 

Our  Continuing  Role  as  a  Demonstration  Site  for  Tele-health  Technology 

Throughout  all  phases,  the  Armstar  Network  is  being  used  as  a  demonstration  site  to 
determine  the  usefulness  of  telehealth  technology  and  information  sharing  in  addressing 
the  problems  of  access  in  the  rural/remote  environment. 
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In  Phase  II  we  specifically  set  out  to  determine  how  comprehensive  electronic  medical 
records  have  to  be  to  be  useful  throughout  the  continuum  of  providers  and  whether  the 
technology  can  be  made  easy  enough  to  use  that  it  becomes  a  practical  tool  to  clinicians. 
Phase  H  can  be  summarized  as  a  set  of  four  tasks  as  follows: 

1)  We  developed  a  working  hardware  and  software  prototype  to  convert  health 
records  only  available  on  paper  into  an  electronic  format  that  can  be  shared 
among  providers. 

2)  We  implemented  and  evaluated  remote  access  technology  for  two  healthcare 
service  areas  that  are  typically  underserved  in  rural/remote  communities. 

3)  We  field  tested  personal  digital  assistant  devices,  PDA’s,  to  determine  if  they 
interfere  with  emergency  medical  treatment  services  when  used  by  EMT 
personnel  at  the  emergency  care  site  or  en-route  to  a  hospital. 

4)  We  implemented  integration  technology  and  developed  a  common  information 
portal  for  access  to  disparate  software  and  hardware  systems  at  the  clinicians’ 
desktops. 

This  report  details  the  activities,  findings,  and  the  most  likely  path  forward  for  each  task. 
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TASK  1 

ABSTRACTING  LEGACY  PATIENT  RECORDS  INTO  ELECTRONIC 
MEDICAL  RECORDS  MANAGEMENT  SYSTEMS 


Objective: 

Find  a  low-cost  process  to  convert  unformatted,  handwritten  medical  records  into  pieces 
of  discrete  healthcare  information  that  can  be  integrated  into  any  electronic  record. 

As  the  field  of  primary  health  care  begins  to  embrace  the  use  of  computers  for  clinical 
documentation,  the  facility  of  these  information  systems  is  limited  by  the  need  for 
historical  information  found  only  in  paper  charts.  As  deployed  armed  forces  units  and 
their  dependents  move  from  community  to  community  over  time  and  seek  the  services  of 
healthcare  providers  within  those  communities,  they  carry  their  charts  with  them.  But 
even  though  the  complete  medical  history  is  in  the  charts,  there  is  increased  risk  of 
missed  diagnoses  and  likelihood  that  services  will  be  duplicated  because  the  time 
available  for  new  physicians  to  review  those  handwritten  charts  is  limited. 

Approach  and  Scope: 

We  developed  an  electronic  template,  integrated  with  several  types  of  low-cost  data 
capture  technology,  to  guide  medically  competent  individuals  in  the  process  of 
abstracting  discreet  information  from  scanned  images  of  paper  records.  To  minimize  the 
costs  to  develop  the  working  prototype  of  this  Clinical  Data  Architecture  (CD  A)  and 
most  quickly  bring  it  to  field  testing,  we  limited  the  information  to  be  abstracted  to 
information  that  is  considered  “care  critical”  in  emergency  situations.  We  contracted 
with  the  Pennsylvania  State  University,  Applied  Research  Laboratory,  to  perform  this 
task. 

Deliverables: 


1)  Define  “care-critical”  patient  information. 

2)  Analyze  the  current  state  of  the  art  technology. 

3)  Decide  the  format  of  “care  critical”  patient  information  and  design  the  database 
schema. 

4)  Develop  a  working  prototype  for  field  tests. 

Results: 


1)  Define  “care-critical”  patient  information:  In  order  to  define  the  elements  of  care 
critical  patient  information,  physicians  of  different  specialties  supplied  a  list  of  what 
they  considered  the  “care-critical”  information.  From  these  lists,  the  investigators 
compiled  a  composite  list  to  determine  the  chart  extractions  that  were  identified 
consistently  by  the  physicians  and  the  number  of  times  they  appeared  in  the 
physicians’  lists.  Emergency  department  and  primary  care  physicians  then  met  with 
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the  project  investigators  to  discuss  the  compiled  information  and  agree  upon  the 
critical  patient  information. 

2)  Analyze  the  current  state  of  the  art  technology.  We  learned  that  there  are  numerous 
potential  technologies  currently  or  soon  to  be  available  that  have  the  potential  to 
satisfy  the  necessary  functional  requirements  for  abstracting  legacy  patient  records 
into  electronic  medical  records.  These  include  optical  character  recognition, 
intelligent  character  recognition,  handwriting  recognition,  voice  recognition, 
eye/body  movement  detection,  and  natural  language  processing.  Due  to  this  wide 
range  of  options,  the  investigative  team  applied  specific  criteria,  including  accuracy 
of  results,  increased  productivity,  user  friendliness  and  cost  to  the  technologies 
evaluated.  Using  web  searches,  conference  attendance,  company  representative 
discussions,  and  application  of  the  team’s  significant  experience  in  the  area,  six 
software  and  hardware  technologies  were  selected  for  initial  investigation.  This 
research  revealed  that  no  single  technology  satisfies  all  the  requirements  for 
efficiently  converting  paper  medical  records  into  electronic  form.  However, 
keyboard  entry,  voice  recognition,  handwriting  recognition,  and  optical  character 
recognition  in  combination  appear  to  have  the  potential  to  provide  a  realistic  and 
practical  solution  for  this  challenge.  The  team  decided  to  use  HL7  standard  software 
for  transmitting  medical  information  between  computerized  systems  and  as  the 
standard  for  storing  the  electronic  medical  record  abstracted  from  the  paper  medical 
records.  The  State  Of  The  Art  Technology  Report  is  attached  as  Appendix  A. 

3)  Decide  the  format  of  care-critical  patient  information  and  design  the  database 
schema:  The  format  of  critical  patient  information  is  driven  by  two  requirements,  the 
logical  categories  of  critical  patient  information  as  arranged  by  the  medical  providers 
and  the  order  and  arrangement  of  information  as  handled  by  the  provider’s  automated 
patient  record  system  if  one  is  available.  This  format  became  the  basis  of  a  design 
template  for  critical  patient  information.  The  logical  categories  were  identified 
during  the  process  of  defining  “care  critical”  patient  information.  In  an  effort  to 
complete  the  second  requirement,  the  investigative  team  met  with  staff  from  Penn 
State  Geisinger  Health  System  to  learn  how  they  approached  paper  record  conversion 
and  what  lessons  were  learned.  This  resulted  in  the  development,  review,  and 
modification  of  a  paper  format  that  eventually  became  the  design  template  for  the 
electronic  format.  The  database  schema  design  is  attached  as  Appendix  B. 

4)  Develop  a  working  prototype  for  field-testing:  A  user  interface  for  field  trials  has 
been  developed  that  integrates  the  template,  an  electronic  archive,  a  thesaurus,  and 
digital  transcription  system  with  an  electronic  repository.  A  user  shell  has  been 
configured  to  allow  for  experimental  connectivity  to  the  Armstar  integrated 
healthcare  information  network.  The  team  anticipates  having  one  medical  provider 
participate  in  a  field  test  for  approximately  three  months,  February  -  April  2004.  A 
technology  overview  of  this  prototype  is  attached  as  Appendix  C. 

Summary  of  Findings: 
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Given  the  constraints  of  designing  an  efficient,  low-cost  system,  we  found  no  single  user 
interface  worked  well  in  all  circumstances.  Because  our  prototype  had  to  be  designed  to 
accommodate  records  from  any  provider,  we  could  make  no  assumptions  about  the 
legibility  or  physical  conditions  of  the  documents.  We  found  that  technology  capable  of 
the  fastest  data  conversion  was  least  able  to  maintain  consistent  accuracy  when  the 
qualities  of  the  documents  were  poor.  The  greater  need  for  human  intervention  actually 
lengthened  the  time  required  for  the  process.  We  also  learned  that  variations  in  processes 
cause  one  technology  to  be  favored  over  another.  For  example,  a  clinician  practice 
utilizing  the  system  to  convert  all  records  to  an  electronic  format  prior  to  implementation 
of  an  EMR  had  different  requirements  than  a  practice  desiring  to  convert  records  one  at  a 
time  as  patients  were  scheduled  for  new  appointments.  We  found  that  it  was  necessary  to 
provide  several  options  for  data  collection  and  abstraction  allowing  the  end  user  to 
determine  the  appropriate  balance  between  collection  speed  and  detail  of  abstraction. 

The  prototype  specification  was  designed  with  the  flexibility  to  substitute  one  interface 
for  another  on  demand  during  the  abstraction  process. 

Although  the  design  flexibility  required  a  variety  of  input  devices  we  were  still  able  to 
design  the  entire  system  so  that  equipment  costs  would  total  less  than  $10,000.  And  in 
spite  of  the  variability  of  document  quality,  researchers  conducting  laboratory  tests  of  the 
system  were  able  to  complete  the  abstraction  process  in  an  average  of  15  minutes  per 
chart  once  they  became  competent  in  the  technology  use.  The  prototype  description  is 
provided  in  Appendix  C. 

Path  Forward: 


Field  tests  of  the  prototype  will  be  conducted  between  February  and  April  2004.  The 
results  of  field  tests,  which  will  better  define  how  users  envision  the  overall  system 
functioning,  will  be  incorporated  into  a  second-generation  system  designed  for 
operational  field  testing  in  multiple  medical  offices  with  real-time  connections  to  the 
Armstar  integrated  healthcare  information  network.  The  design  of  the  Armstar  model, 
however,  presents  concerns  that  must  be  overcome  before  the  technology  is  implemented 
in  the  “live”  environment. 

The  Armstar  repository  is  not  designed  to  duplicate  or  replace  individual  providers’ 
records.  It  is  designed  to  facilitate  the  aggregation  and  integration  of  those  records.  To 
include  records  that  are  not  in  any  electronic  format  requires  that  the  host  organization,  in 
this  case  ACMH,  provide  storage  for  the  information.  Certain  healthcare  information  is 
static,  the  dates  of  and  reasons  for  past  hospital  admissions  or  surgical  procedures.  Other 
information  is  dynamic  such  as  a  patient’s  fist  of  current  medications.  Static  information 
requires  adequate  storage  capability  to  allow  information  to  accumulate.  Dynamic 
information  must  be  kept  current.  These  challenges  will  be  addressed  in  Phase  II  add-on. 

In  Phase  HI,  following  the  development  of  processes  to  address  the  concerns  and  the 
completion  of  the  second-generation  system,  research  subjects  will  be  solicited  for  the 
purpose  of  assessing  the  usefulness,  completion  and  accuracy  of  the  healthcare 
information.  Participants  will  authorize  the  abstracting  of  their  “care-critical”  healthcare 
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information  into  the  repository  and  will  consent  to  a  conditional  release  of  that 
information  to  healthcare  providers  participating  in  the  research.  In  this  phase,  we  will 
introduce  a  wallet-size  healthcare  information  card  that  contains  the  location  of  the 
network  hub  that  hosts  the  “care  critical”  information  and  the  access  key. 
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TASK  II 

DEMONSTRATE  THE  USE  OF  INFORMATION  TECHNOLOGY  TO 
IMPROVE  ACCESS  TO  HEALTHCARE  SPECIALISTS 


Objective: 

Evaluate  how  remote  access  to  healthcare  information  can  increase  the  productivity  of 
specialists  when  serving  rural  communities.  We  selected  wound  healing  for  homebound 
patients  and  radiological  image  interpretation  as  our  areas  of  focus. 

In  rural  areas,  as  in  many  of  the  areas  where  military  personnel  are  deployed,  specialists 
are  often  not  available.  These  professionals  are  generally  located  in  highly  populated 
urban  areas  where  their  demand  is  strong.  Distance,  a  lack  of  transportation  systems,  and 
rural  geographic  conditions  impede  travel  by  patients  to  those  urban  areas.  We  believe 
that  computer  technology  and  healthcare  informatics  can  be  used  to  mitigate  those 
shortages. 

Interest  in  such  technology  has  grown  dramatically  in  recent  years,  with  an  estimated  50- 
fold  utilization  increase  in  telemedicine  during  the  1990s  in  the  United  States.  But  the 
healthcare  industry’s  use  of  remote  access  to  information  still  lags  far  behind  others  due 
to  a  lack  of  resources  and  legal,  cultural,  and  social  barriers.  We  hope  that  our  successful 
demonstrations,  along  with  those  in  other  communities,  will  help  prove  the  value  of  the 
technology  and  break  through  the  barriers. 

Wound  Care  -  Approach  and  scope: 

In  the  area  of  wound  care  for  homebound  patients,  we  equipped  ACMH  home  health 
nurses  and  aides  with  digital  cameras  to  photograph  patient  wounds,  such  as  pressure 
ulcers  or  other  chronic  wounds.  ACMH  contracted  with  a  software  vendor  to  store  the 
images  on  line  with  related  documentation.  The  software  used  for  the  trial  was 
WoundExpert.  The  records  were  made  available  to  physicians  and  personnel  at  the 
ACMH  wound  healing  center. 

Wound  Care  -  Deliverables  and  Findings: 

From  October  2001  through  March  2002,  we  gathered  base-line  data  as  followed: 

•  Annual  home  health  patients  treated  -  1 1 56. 

•  Annual  visits  by  homecare  nurses  or  aides  -  16,460. 

•  Number  of  patients  treated  with  wounds  -  58. 

•  Annual  visits  for  wound  care  -  926. 

This  baseline  data  shows  that  an  average  of  16  visits  are  required  for  the  wound  patient. 
The  average  for  all  patients,  including  wound  patients,  is  14.24.  We  postulated  that 
telemedicine  could  be  used  to  improve  the  collaboration  among  patients,  primary  care 
physicians,  and  wound  care  specialists,  to  reduce  the  average  time  interval  between 
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evaluation  and  treatment  intervention.  This  would  result  in  fewer  average  visits  for 
wound  care,  a  reduction  in  cost. 

In  November  2002,  the  investigative  team  purchased  digital  cameras  to  be  piloted.  Home 
health  nurses  were  trained  to  use  these  cameras  in  conjunction  with  their  laptops  used  to 
document  patient  care.  Home  health  patients  who  failed  to  respond  to  traditional  wound 
treatment  methods  had  their  wounds  photographed  by  the  home  health  nurses  using  the 
digital  cameras.  These  images  were  then  transmitted  to  the  WoundExpert  database, 
making  the  images  viewable  by  primary  care  physicians  or  wound  care  specialists  who 
would  make  a  recommendation  regarding  the  clinical  plan  for  that  patient. 

We  found  that  the  improved  technology  did  little  to  facilitate  access  to  wound  care 
specialists  because  the  specialists  were  often  not  available  at  the  time  home  care 
personnel  were  visiting  the  patient.  The  team  tried  scheduling  wound  care  visits  to 
coincide  with  times  that  wound  healing  personnel  were  available  but  the  nature  of  the 
rural  geographic  environment  made  clinician  arrival  times  unreliable.  As  a  result,  only 
five  consultations  were  facilitated  with  wound  healing  personnel,  not  enough  to  form  any 
conclusions. 

Nevertheless,  we  found  that  we  were  still  able  to  reduce  the  number  of  visits  for  wound 
care  patients.  Post  implementation  data  shows  we  were  able  to  accommodate  762  visits 
for  165  wound  care  patients.  This  is  a  marked  decrease  from  16  visits  per  patient  to  4.6 
visits  per  patient--an  improvement  factor  of  four.  We  have  attributed  this  improvement 
to  closer  coordination  between  the  home  health  nurse  and  the  primary  care  physician. 

Remote  Radiology  -  Approach  and  scope: 

To  provide  remote  access  to  radiological  images,  we  implemented  Picture  Archiving  and 
Communications  System  (PACS)  technology  and  integrated  it  with  the  Armstar 
repository.  The  specific  PACS  was  selected  based  upon  its  ability  to  provide  image¬ 
viewing  software  that  runs  on  common  desktop  computer  systems.  While  future  plans 
include  the  integration  of  images  associated  with  other  clinical  disciplines  such  as 
cardiology  and  obstetrics,  we  limited  PACS  images  to  radiology  in  this  phase 

Remote  Radiology  -  Deliverables  and  Findings: 

In  May  2002,  a  committee  comprised  of  radiologists,  information  service  staff, 
technologists,  and  hospital  administrators  was  formed  to  conduct  a  needs  assessment  and 
determine  selection  criteria  for  a  PACS.  In  addition  to  cost  and  benefits,  criteria  were 
developed  to  address  facility  requirements,  teleradiology  (remote)  requirements  and  the 
ability  to  integrate  the  PACS  with  the  Armstar  repository.  The  PACS  committee  created 
a  formal  Request  for  Proposal  (RFP)  for  purchase,  implementation,  and  ongoing 
support/maintenance  of  an  integrated  PACS  solution.  Five  vendors  responded  to  the  RFP 
and  provided  on-site  demonstrations.  Visits  to  imaging  facilities  using  the  systems  were 
arranged  for  the  two  systems  evaluated  most  highly  by  the  committee.  DR  Systems 
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PACS  was  chosen  because  it  was  the  most  cost  efficient  and  provided  the  best  fit  with  the 
Armstar  goals. 

The  Thomas  Group,  Ltd.  was  contracted  to  facilitate  the  selection  and  implementation  of 
PACS.  A  summary  report,  prepared  by  Dale  Hunt  of  the  Thomas  Group,  is  attached  as 
Appendix  E. 

At  ACMH,  the  range  of  case  turn  around  time  for  radio  logic  studies  improved  from  1-5 
hours  before  PACS  to  0-1  hours  after  PACS.  Additionally,  film  expense  decreased  by 
$2780  per  week.  Film  printing  was  reduced  by  $1244  per  week. 

Path  Forward: 

We  will  expand  PACS  to  include  images  from  other  healthcare  disciplines  and  will 
continue  to  act  as  a  test  bed  for  telemedicine  trials. 
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TASK  III 

VALIDATING  WIRELESS  HAND-HELD  ELECTRONIC  DEVICES  ASSISTING 
EMERGENCY  MEDICAL  FIELD  PERSONNEL 


Objective: 

Determine  whether  paramedics  can  utilize  electronic  devices  (PDA’s)  to  collect  clinical 
and  demographic  data  before  arriving  at  a  hospital  emergency  department.  We  wanted  to 
ascertain  whether  the  devices  interfere  with  the  care  of  the  patient. 

Approach  and  Scope: 

Through  a  partnership  with  the  Pennsylvania  State  University  Applied  Research 
Laboratory  and  Armstrong  County  EMS  personnel  we  conducted  a  field  demonstration  to 
investigate  the  usefulness  and  validate  the  benefits  and/or  failures  of  handheld  electronic 
devices,  called  personal  digital  assistants  (PDA's).  Paramedics  from  5  volunteer  hose 
companies  covering  all  of  the  ACMH  service  area  participated  in  the  project.  We 
observed  how  and  when  the  data  was  collected,  the  device  ease  of  use,  and  the  perceived 
benefit  to  EMS  personnel. 

Task  Deliverables: 


1)  Develop/acquire  the  software  application  for  the  PDA  that  is  effective  in 
collecting  the  data. 

2)  Develop/acquire  a  database  management  infrastructure: 

3)  Demonstrate  the  application  in  field  use  and  make  modifications  as  necessary. 

Results: 


1)  Develop/acquire  the  software  application  for  the  PDA.  EMS  and  ER  personnel 
were  involved  in  the  decision  to  select  EMStat,  a  desktop  patient  reporting  system 
and  REMStat,  PDA  software  developed  by  Med-Media,  Inc.  The  only 
modification  required  was  the  incorporating  of  the  names  of  ACMH  physicians 
and  the  customizing  of  some  drop  down  menus  to  reflect  ACMH  information 

2)  Develop/acquire  the  database  management  infrastructure.  The  cellular 
communication  coverage  north  of  ACMH  is  “spotty”  at  best  due  to  the  area  being 
sparsely  populated.  Consequently,  wirelessly  communicating  data  to  the  ER  was 
not  possible.  In  light  of  this,  no  ER  database  management  infrastructure  was 
required  to  support  this  phase  of  the  project.  This  problem  was  easily  mitigated. 
Upon  arrival  at  the  ER,  EMS  personnel  print  the  patient  data  via  the  infrared  port 
providing  the  ER  Doctor  with  the  patient  information  collected  in  the  field. 

The  EMStat  system  provided  the  infrastructure  to  populate  individual  repositories 
residing  at  each  hose  company.  All  five  EMS  services  directly  populate  their 
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patient  care  information  database  exclusively  by  electronic  means  using  the 
PDA's. 


Demonstrate  the  application  in  field  use:  Four  EMS  services,  Dayton,  Kittanning, 
Ford  City,  and  Sugar  Creek,  have  been  involved  in  field  use  since  January  2003. 
Startup  at  a  fifth  service,  Worthington,  was  delayed  due  to  personnel  changes 
after  a  county  election.  All  five  are  now  documenting  paramedic  care  daily  using 
the  PDA's.  Some  statistics  on  PDA  use  per  month  are: 

•  Dayton  -  50 

•  Kittanning  -  300 

•  Ford  City- 150 

•  Sugar  Creek  -  80 


Findings: 

There  have  been  minor  adjustments  made  to  the  PDA’s,  such  as  re-installation  of 
software,  but  no  major  challenges  have  surfaced.  All  five  services  report  very  positive 
feedback  using  the  PDA’s. 

Some  data  is  entered  into  the  PDA  via  a  keyboard  or  by  using  “Graffiti”  handwriting 
inherent  in  the  PDA.  En  route  to  the  emergency  room,  EMS  personnel  also  input  patient 
data  such  as  assessment  information,  medications  given,  etc.,  into  the  PDA’s  by  checking 
offboxes  that  offer  specific  information.  This  greatly  reduces  the  risk  of  entering 
incorrect  information.  Once  at  the  ER,  they  print  from  the  PDA  via  the  infrared  port  to 
the  emergency  room  printer  a  record  for  use  by  the  ER  staff.  That  report  is  incorporated 
into  the  patient’s  ER  chart. 

Additionally,  the  PDA  software  allows  EMS  personnel  to  complete  the  Pennsylvania 
EMS  Report,  required  by  the  state  of  Pennsylvania,  electronically  using  a  “Hot  Sync” 
feature.  This  method  reduces  dependency  on  memory,  the  burden  of 
administrative/reporting  tasks,  and  the  “down  time”  between  answering  calls,  increasing 
available  field  time  to  attend  to  patients.  The  EMStat  system  provides  a  valuable  tool  to 
extrapolate  information  from  the  trip  reports,  such  as  time  of  heaviest  response,  call 
severity  and  most  frequent  day  of  the  week  response. 

Path  Forward: 

In  Armstar  Phase  HI,  the  performance  improvements  documented  in  Phase  II  will  be 
confirmed  for  EMTs  in  surrounding  rural  communities. 
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TASK  IV 

EXPANSION  OF  THE  HEALTHCARE  INFORMATION  NETWORK, 
SYNCHRONIZATION  OF  THE  DESKTOP  APPLICATIONS,  PORTAL  AND 

INTERFACE  DEVELOPMENT 


Objective: 

Show  that  disparate  systems,  even  when  owned  by  independent  organizations,  can  be 
integrated  at  the  desktop  and  that  such  integration  will  increase  clinical  access  to  the 
remote  applications. 

Background: 

Maintaining  a  degree  of  both  patient  choice  and  professional  autonomy  within  a 
healthcare  system  calls  for  the  efficient  transfer  of  patient  information  to  and  from 
authorized  providers  of  services.  Recent  studies  have  shown  that  computer  technologies 
can  improve  collaboration  among  healthcare  providers  in  the  areas  of  efficiency, 
frequency,  and  democratic  dialogue. 

Preventive  and  primary  healthcare  in  rural  communities  is  mostly  provided  by 
independent  practitioners.  Many  of  these  providers  lack  both  the  financial  and  technical 
resources  to  acquire  and  support  electronic  patient  record  systems.  The  clinical 
information  systems  that  are  acquired  by  some  do  not  readily  interface  with  the  systems 
of  others.  Most  communication  of  healthcare  information  in  rural/remote  areas  is  via 
paper. 

It  is  our  belief  that  the  rural  community  hospital,  often  the  largest  provider  with  the  most 
resources,  should  function  as  a  collaboration  hub  to  enable  electronic  health  information 
transfer  among  independent  practitioners.  In  Phase  I  of  this  project,  ACMH  was 
positioned  as  that  hub  within  Armstrong  County,  making  hospital  information  available 
to  physicians  in  their  offices  and  developing  interfaces  and  mapping  tables  that  logically 
integrate  disparate  information  systems.  In  this  task,  the  work  completed  in  Phase  I  has 
been  expanded  upon  in  order  to  fully  demonstrate  the  utilization  of  the  technologies 
acquired  and  developed  in  tasks  I-IH  within  this  report. 

Task  Deliverables: 


1)  Developed  and  implemented  robust  and  standardized  integration  methodologies. 

2)  Contracted  with  legacy  system  vendors  to  retrofit  systems  currently  being  used  by 
ACMH  to  support  the  Armstar  information  repository. 

3)  Developed  a  web-enabled  physician  information  portal  (PIP)  that  includes  an 
authentication  repository  with  custom  linkages  for  access  and  two-factor 
authentication  to  protect  patient  privacy  and  network  reliability. 
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Progress: 


1)  Developed  and  implemented  robust  and  standardized  integration  methodology: 

In  January  2003,  a  Task  I  team  member  attended  the  HL7  Working  Group 
meeting.  HL7  is  a  medical  industry  standard  for  moving  medical  information 
from  one  place  to  another.  This  meeting  enabled  the  member  to  learn  the 
fundamentals  of  the  Health  Level  Seven  (HL7)  standard  and  analyze  what  parts  of 
the  standard  could  be  applied  to  the  ARMSTAR  project.  On  return,  he  evaluated 
the  HL7  Clinical  Document  Architecture  (CD A)  with  other  team  members  and 
determined  that  the  CDA  satisfies  the  requirement  capturing  historical  medical 
record  information  in  a  structure  that  can  be  read  by  humans  and  processed  by 
machine. 

A  second  team  member  attended  the  May  2003  HL7  Working  Group  meeting  to 
learn  how  to  develop  applications  that  produce  medical  records  in  the  CDA 
format.  The  team  has  since  written  Java  code  to  produce  CD  As  in 
compliance  with  the  HL7  standard. 

Other  team  members  implemented  the  HL7  transmission  structure  in  the 
interfaces  developed  to  link  the  disparate  information  systems.  An  integration 
engine  was  acquired  in  Armstar  Phase  I  and  is  maintained/supported  by  ACMH 
with  non-federal  funds.  It  has  been  a  key  component  of  the  Armstar  infrastructure 
and  is  the  platform  used  to  eliminate  the  need  for  point-to-point  interfaces. 

2)  Contracted  with  legacy  system  vendors  to  retrofit  systems  currently  being  used  by 
ACMH  to  support  the  Armstar  information  repository: 

The  patient  information  repository,  Patient  View,  an  HBOC  product  was  replaced 
with  the  Meditech  Client  Server  Electronic  Medical  Record  (EMR)  in  January 
2003,  supporting  a  more  comprehensive  array  of  data  objects.  Transcribed 
reports,  such  as  histories  and  physicals  and  operative  reports  were  added  to  the 
database  of  lab  and  radiology  results.  Technology  to  support  clinical  data 
trending  was  added.  Electronic  signature  capability  was  added  along  with  the 
capability  of  remote  order  entry.  These  activities  were  funded  by  ACMH  and 
utilized  no  federal  funds. 

Radiological  images  were  not  physically  added  to  the  repository  but  logically 
added.  The  EMR  invokes  an  image  viewer  and  fetches  the  images  from  the 
PACS  to  provide  access  to  primary  care  providers  and  specialists  through  the 
common  information  portal.  This  technology  is  being  tested  at  the  time  of  this 
writing. 
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4)  Developed  a  web-enabled  physician  information  portal  (TIP)  that  includes  an 
authentication  repository  with  custom  linkages  for  access  and  two-factor 
authentication  to  protect  patient  privacy  and  network  reliability. 

Single  sign-on  HIPAA  compliant  access  to  the  Physician  Information  Portal  (PIP) 
was  accomplished  using  a  Cisco  Secure  Access  Server  which  houses  user  names, 
passwords,  and  access  lists  for  all  users  using  the  PIP.  Profiles,  at  various  levels, 
were  developed  for  each  classification  of  user,  thereby  maximizing  the  ease  of  use 
and  augmenting  the  application  level  security.  Profiles  classify  data  as  either 
clinical  or  demographic.  Patient  episodes  are  classified  as  normal  confidentiality 
vs.  heightened  confidentiality,  which  require  special  authorization  for  release. 

The  profiles  also  limit  the  breadth  of  access  to  data.  Access  policies,  where 
possible,  were  based  upon  the  “need  to  know”  rather  than  the  “right  to  know.” 

A  position  paper  describing  ACMH  methods  of  protecting  personal  health 
information  is  attached  as  Appendix  F. 

A  network  schematic  is  attached  as  Appendix  G. 

Path  Forward 

In  Armstar  Phase  m,  the  Physician  Information  Portal  (PEP)  capability  will  be  universally 
used  throughout  Armstrong  County  and  transitioned  to  another  rural  community.  PIP 
will  serve  as  the  interface  for  accessing  the  “hub”  for  remote  “care-critical”  patient 
information  transfer. 
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Purpose 


Physicians  need  affordable  and  streamlined  process  to  migrate  critical  patient  information 
from  legacy,  paper-based  patient  records  into  an  electronic  format  that  is  compatible  with 
information  technology  that  can  be  successfully  employed  in  the  rural  healthcare  delivery 
system  to  overcome  resource  shortages  and  improve  collaboration  among  service 
providers. 

This  document  summarizes  the  first  step  in  satisfying  this  requirement  -  evaluating  state 
of  the  art  technologies  -  defined  in  the  statement  of  work  as: 

“Analyze  the  current  state  of  the  art  for  automatically  extracting  data  from  paper- 
based  records  as  it  applies  to  this  challenge.  The  technology  search  will  not  be 
limited  to  the  healthcare  industry.” 

The  ARL  team  investigates  computing,  software,  human  interfaces  and  information 
standards  technologies  in  this  report. 


Background 

Armstrong  County  Memorial  Hospital  provided  40  medical  records  to  the  ARL  team 
representative  of  the  information  that  needs  to  be  converted  from  paper-based  to 
electronic  form.  The  medical  records  do  not  have  a  consistent  structure,  order  or  content 
and  there  are  several  formats  for  recording  the  same  information.  All  records  have 
handwritten  notes  with  the  expected  wide  variations  in  legibility.  Many  records  have 
ambiguous  entries  in  form  fields,  such  as  a  list  of  checkboxes  with  checkmarks  in 
between,  that  can  frequently  be  resolved  by  a  person  reading  additional  information  on 
the  form. 

Criteria  for  Technology  Candidates 

Though  there  are  many,  many  potential  technologies  currently  or  soon  to  be  available  to 
satisfy  the  functional  requirements,  the  team  applied  the  criteria  below  to  the 
technologies  evaluated. 

•  Physicians  must  be  confident  in  the  accuracy  of  the  results. 

•  New  technology  must  collectively  increase  productivity  over  manual  data  entry 
into  electronic  health  record  systems. 

•  New  technology  must  be  presented  in  a  simple  and  intuitive  user  interface. 

•  Software  and  hardware  technologies  must  be  affordable  for  rural  physicians  (less 
than  $10,000  total)  when  commercialized. 

•  New  technologies  should  require  little  physical  space,  i.e.,  do  not  require  a 
separate  room  or  closet  for  computers,  scanners  and  storage. 

•  End-user  training  time  must  be  in  hours,  not  days. 

•  Solutions  must  maximize  use  of  open  standards. 

•  Solutions  should  incorporate  commercially  available  tools  that  allow  developers 
to  customize  their  implementation. 

The  ARL  team  evaluated  technologies  candidates  by  conducting  web  searches,  attending 
conferences,  participating  in  webinars  and  speaking  with  company  representatives.  The 
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team  also  brings  forward  experience  from  prior  research  conducted  with  related 
technologies. 


Hardware  and  Software  Technologies  Investigated 

ARL/PSU  engineers  investigate  six  software  and  hardware  technologies  summarized 
below  against  the  criteria  above.  ' 

Optical  Character  Recognition 

Summary 

There  are  two  general  classes  of  OCR  technologies.  At  the  simplest  level,  an  OCR  form 
recognition  software  package  is  used  to  scan  form-based  medical  documents  that  have 
consistent  structure  and  machine  typed  information.  Most  software  packages  look  for 
“zones”  on  a  preprinted  form  and  save  the  information  scanned  from  those  zones  into 
predefined  data  structures  or  fields  in  a  table  in  a  database.  There  are  useful  variations  of 
this  technology  such  as  scanning  a  form  for  predefined  graphical  elements  like  a  mark 
from  rubber  stamp  and  then  scanning  for  hand  written  information  within  it.  Finally, 
technologies  are  evolving  to  handle  unstructured  forms  that  are  forms  with  standard 
content  but  not  the  same  structure,  such  as  invoice  forms  from  different  vendors. 

Maturity  and  Suitability 

OCR  is  relatively  mature  when  compared  to  the  other  technologies  assessed  in  this  report. 
New  products  from  companies  such  as  ScanSoft  are  full  featured  and  affordable. 
However,  there  is  no  consistency  in  the  forms  in  the  sample  medical  records  we  have 
evaluated  thus  limiting  the  utility  of  OCR  technology  for  this  project.  The  technology 
could  be  suitable  for  one  practice  that  uses  the  same  forms  consistently,  however,  it  may 
not  be  suitable  for  multiple  practices  using  different  forms  and  following  different 
procedures. 

Intelligent  Character  Recognition 
Summary 

Intelligent  Character  Recognition  (ICR)  is  similar  to  optical  character  recognition  (OCR) 
but  is  focused  on  converting  handwriting  to  data.  It  can  be  used  in  combination  with 
OCR  in  form  processing. 

Maturity  and  Suitability 

Like  OCR,  ICR  is  mature  when  compared  to  the  other  technologies  assessed  in  this 
report.  Today  commercial  products  still  only  perform  well  with  handprint  isolated  in 
predefined  form  fields,  not  unstructured  notes  such  as  those  found  in  medical  records. 

Hand  Writing  Recognition 

Summary 

There  are  many  technologies  available  for  entering  information  into  computers  using 
handwriting  and  the  degree  of  flexibility  is  limited  by  computing  power.  Computing 
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platforms  with  minimal  computing  power,  such  as  the  Palm  Pilot,  require  handwriting  to 
be  well  defined  and  structured.  In  late  2002,  Microsoft  and  hardware  vendors  introduced 
Tablet  PCs  running  the  Windows  XP  Tablet  operating  system  that  use  natural 
handwriting  (both  print  and  cursive)  for  data  input.  The  Tablet  PCs  are  typically 
powered  by  Pentium  III  (or  similar)  1GHz  processors,  have  256MB  or  more  of  RAM, 
and  have  10”-12”  displays. 

The  Tablet  PCs  contain  digitizers  that  overlay  the  LCD  screens  and  create  an 
electromagnetic  field.  When  the  special  Tablet  PC  pen  contacts  the  screen's 
electromagnetic  field,  the  pen's  motion  translates  on  the  screen  to  a  series  of  data  points. 
As  the  user  moves  the  pen  across  the  screen,  a  digitizer  uses  a  sampling  process  to  collect 
the  pen's  movement  information.  The  digitizer  can  sample  130  data  points  per  second. 
The  data  points  that  the  digitizer  samples  are  then  rendered  on  screen  as  pen  strokes. 
Because  the  sampling  rate  is  so  high,  the  Tablet  PC  can  display  and  store  the  digital  ink 
with  a  high  graphical  resolution,  which  contributes  to  on-screen  legibility  and  maximizes 
the  accuracy  of  the  handwriting  recognition  process. 

The  technology  underlying  real  time  handwriting  recognition  in  Windows  XP  tablet  is 
Hidden  Markov  Models  (HMMs).  HMMs  are  stochastic  models  that  can  deal  effectively 
with  pattern  variation  and  noise,  and  have  successfully  been  applied  to  the  modeling  of 
time  varying  dynamic  patterns  as  in  the  case  of  speech  and  on-line  handwriting 
recognition.  During  recent  years,  HMMs  have  also  been  applied  to  the  recognition  of  off¬ 
line  cursive  script,  however  the  results  have  been  less  successful  due  to  the  difficulty  of 
producing  a  consistent  sequence  of  feature  vectors  from  the  input  word  image. 


Maturity  and  Suitability 

Although  Palm  Pilots  and  PocketPCs  have  been  available  and  stable  for  years  they  do  not 
have  the  computing  power  or  the  display  size  required  for  this  project.  Tablet  PCs  are 
relatively  new  packaging  and  integration  of  existing  technologies  and  appear  to  be 
promising  for  this  project.  Pen  Writer’s  are  relatively  new,  but  stable. 

Voice  Recognition 

Summary 

Speech  recognition  technology,  the  foundation  of  high-performance  speech  recognition 
systems,  involves  complex  statistical  models  that  characterize  the  properties  of  sounds, 
taking  into  account  factors  such  as  male  vs.  female  voices,  accents,  speaking  rate, 
background  noise,  etc.  The  process  of  speech  recognition  includes  5  stages:  Capture  and 
Digitization;  Spectral  Representation;  Segmentation;  Phonetic  Modeling;  and  Search  and 
Match. 

Commercial  off-the-shelf  voice  recognition  packages  recognize  spoken  words  and 
convert  to  text  for  use  in  other  applications.  Current  state  of  the  art  is  keyword-based 
systems  that  are  just  now  commercially  available.  Dictionary  based  systems  have 
improved  to  the  point  of  high  accuracy  (some  claim  99%). 
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Audio  Mining  is  a  new  and  growing  technology  just  recently  introduced  into  the  voice 
recognition  software  and  was  developed  to  support  Natural  Language  Processing. 
Broadcast  companies  are  using  audio  mining  tools  to  convert,  index  and  classify  audio 
from  speeches,  presentations  and  newscasts  so  that  then  can  be  “mined”  at  a  later  date  so 
that  users  can  either  read  or  listen  to  excerpts. 

Maturity  and  Suitability 

Dictionary  systems  are  the  most  mature  of  the  voice  recognition  technologies  and  are 
common  and  affordable  in  specialized  domains  such  as  medical,  legal,  construction,  etc. 
Keyword  systems  that  trigger  system  events  or  branches  in  logic  have  emerging  from  the 
research  phase  and  are  used  in  telephone  call  routing  systems.  Audio  mining  is  a 
growing  technology  that  combines  both  keyword  and  dictionary  techniques.  All  three  of 
these  voice  recognition  technologies  can  potentially  be  applied  to  this  project  and  will  be 
evaluated  further. 

Eye/Body  Movement  Detection 

While  eye  and  body  movement  detection  technology  has  made  leaps  and  bounds  over  the 
last  few  years,  affordable  and  practical  devices  for  human-machine  interfaces  have  not 
been  brought  to  the  commercial  market.  Research  at  various  universities  has  suggested 
that  this  will  be  a  viable  technology  in  the  near  future,  however,  affordability  for  rural 
physicians  in  the  next  5  years  is  doubtful. 

One  eye  tracking  system  in  use  at  University  of  Connecticut  is  a  system  known  as  IRIS 
designed  by  Reulen  et  al  and  manufactured  by  Skalar  Medical,  a  Dutch  company.  The 
recorder  exploits  the  difference  in  infra-red  (IR)  reflectance  between  the  iris  and  the 
sclera  of  a  healthy  eye  to  detect  location  of  focus.  The  system  employs  a  horizontal  row 
of  nine  950nm  IR  light  emitting  diodes  (LEDs)  to  illuminate  the  iris/scleral  boundary  on 
both  the  nasal  and  temporal  sides  of  the  eye.  A  corresponding  row  of  nine  photo 
transistors  located  above  the  LEDs  receives  the  reflected  signal.  Transmitter  and  receiver 
assemblies  for  each  eye  are  fitted  into  a  transparent  Perspex  (or  Lucite)  case  attached  to 
an  adjustable  lightweight  metal  head  mount.  Subtraction  of  the  nasal  and  temporal 
detector  signals  from  each  assembly  gives  the  eye  position  with  respect  to  head  position. 

Natural  Language  Processing 

Natural  language  processing  technology  could  greatly  enhance  the  conversion  of  paper- 
based  information  to  electronic  media  via  spoken  words  in  cases  where  the  information  is 
recorded  in  sentence  form  or  the  users  interprets  raw  data  and  speaks  in  complete 
sentences. 

The  main  aim  of  linguistic  theory  is  to  show  how  larger  units  of  meaning  arise  out  of  the 
combination  of  the  smaller  ones  modeled  by  means  of  a  grammar.  Computational 
linguistics  then  tries  to  implement  this  process  in  an  efficient  way  usually  by  subdividing 
the  task  into  syntax  and  semantics.  Syntax  describes  how  the  different  formal  elements 
of  a  textual  unit  like  a  sentence  can  be  combined.  Semantics  describes  how  the 
interpretation  is  calculated.  The  grammar  consists  of  a  lexicon,  and  rules  that 
syntactically  and  semantically  combine  words  and  phrases  into  larger  phrases  and 
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sentences.  Several  natural  language  technology  products  available  today  employ 
annotated  phrase-structure  grammars,  grammars  with  several  hundreds  or  thousands  of 
rules  describing  different  phrase  types.  Each  of  these  rules  is  annotated  by  features  and 
sometimes  also  by  expressions  in  a  programming  language.  One  difficulty  with  phrase- 
structured  grammars  is  that  they  become  difficult  to  maintain,  extend  and  reuse  once  they 
reach  a  certain  size.  The  resulting  systems  might  be  sufficiently  efficient  for  some 
applications  but  they  lack  the  speed  of  processing  needed  for  interactive  systems  (such  as 
applications  involving  spoken  input)  or  systems  that  have  to  process  large  volumes  of 
texts  (as  in  machine  translation). 

Natural-language  processing  of  sentences  is  complex  in  two  ways:  predictively ,  in  that 
not  every  word  is  equally  likely  in  every  context,  and  evidentially,  in  that  the  information 
carried  by  a  sentence  depends  on  the  relationships  among  the  words  in  the  sentence. 
Depending  on  the  application,  one  or  the  other  of  the  two  complexities  can  be  the  forcing 
function. 

Several  organizations  are  studying  and  implementing  natural  language  processing 
technology: 

•  Microsoft  Speech  Technology  Group 

•  The  Butler  Hill  Group 

•  The  Computation  and  Language  E-Print  Archive 

•  Linguistic  Data  Consortium 

The  ARL  team  does  not  envision  using  natural  language  processing  as  part  of  the  final 
solution  since  very  few  of  the  paper-based  medical  records  have  complete  sentences. 

Information  Standards  Investigated 

The  ARL  Team  evaluated  two  related  healthcare  information  standards  for  transmitting 
information  between  healthcare  systems  and  for  persistently  storing  and  presenting  the 
clinical  documents.  Both  standards  are  widely  adopted  in  the  healthcare  industry  and 
both  have  major  revisions  nearing  completion  and  adoption. 

Health  Level  7 (HL7) 

HL7  is  a  global  medical  information  standard  organization  with  approximately  2000 
individual  members  and  500  corporate  members.  Currently  at  version  2.4,  HL7  includes 
standards  for  transmitting  medical  information  between  computerized  systems.  Version 
2.4  messages  use  ASCII  characters  to  separate  fields  and  to  indicate  optional  and 
repeatable  fields.  This  was  a  common  approach  to  system  interfaces  designed  during  the 
1980s  and  1990s.  However,  the  general  approach  is  self-limiting  because  there  is  no 
formal  relationship  between  data  elements.  As  messages  become  more  complex  and  as 
interoperability  requirements  increase  individual  systems  tend  to  fall  behind 
implementing  the  latest  interface  standards  and  point  solutions  evolve,  thus  defeating  the 
intent  of  the  standard. 

HL7  version  3,  nearing  completion  and  adoption,  corrects  the  limitations  of  version  2  by 
creating  on  overall  object  model  for  medical  information  exchange  call  the  “Reference 
Information  Model”,  or  RIM.  The  RIM  is  developed  using  the  Unified  Modeling 
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Language  (UML).  It  consists  of  70  classes,  all  of  which  are  based  on  6  backbone  classes 
described  on  the  HL7  web  site1: 

•  Act  -  represents  the  actions  that  are  executed  and  must  be  documented  as  health 
care  is  managed  and  provided; 

•  Participation  -  expresses  the  context  for  an  act  in  terms  such  as  who  performed  it, 
for  whom  it  was  done,  where  it  was  done,  etc.; 

•  Entity  -  represents  the  physical  things  and  beings  that  are  of  interest  to,  and  take 
part  in  health  care; 

•  Role  -  establishes  the  roles  that  entities  play  as  they  participate  in  health  care  acts; 

•  ActRelationship  -  represents  the  binding  of  one  act  to  another,  such  as  the 
relationship  between  an  order  for  an  observation  and  the  observation  event  as  it 
occurs;  and 

•  RoleLink  -  represents  relationships  between  individual  roles. 

• 

All  future  HL7  messages  and  documents  will  be  based  on  XML  schemas  derived  from 
the  RIM  making  development,  validation  and  implementation  significantly  simpler. 
Refined  Message  Information  Models,  called  R-MIMs,  are  derived  from  the  RIM  for 
related  groups  of  messages  like  “orders”.  Finally,  Hierarchical  Message  Definitions 
(HMDs)  are  developed  for  the  messages  themselves. 

The  ARL  team  envisions  using  HL7  standards  in  two  ways.  In  the  near  term  the  team 
will  likely  use  the  HL7  Clinical  Document  Architecture  as  the  container  for  the  electronic 
medical  record  (described  below).  In  the  future,  and  outside  the  scope  of  this  effort,  the 
team  envisions  using  HL7  messages  to  transmit  the  CDA  documents  like  the  electronic 
medical  record  from  transcription/conversion  systems  to  electronic  health  record 
information  systems  and  document  management  systems. 
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CDA  Documents 


Clinical  Document  Architecture  (CDA) 

The  Clinical  Document  Architecture  is  the  standard  that  ARL  Team  will  use  for  storing 
the  electronic  medical  record  abstracted  from  the  paper  medical  records. 


1  HL7  Web  Site,  http://www.hl7.org/library/ 
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The  HL7  web  site  describes  the  CD  A  as: 

“The  CDA. . .  provides  an  exchange  model  for  clinical  documents  (such  as 
discharge  summaries  and  progress  notes) — and  brings  the  healthcare  industry 
closer  to  the  realization  of  an  electronic  medical  record.  The  CDA  Standard  is 
expected  to  be  published  as  an  ANSI  approved  standard  by  the  end  of  the  year. 

“By  leveraging  the  use  of  XML,  the  HL7  Reference  Information  Model  (RIM) 
and  coded  vocabularies,  the  CDA  makes  documents  both  machine-readable — so 
they  are  easily  parsed  and  processed  electronically — and  human-readable — so 
they  can  be  easily  retrieved  and  used  by  the  people  who  need  them.  CDA 
documents  can  be  displayed  using  XML-aware  Web  browsers  or  wireless 
applications  such  as  cell  phones.”2 

Documents  developed  in  accordance  with  the  CDA  have  the  following  characteristics: 

•  “Persistence  -  A  clinical  document  continues  to  exist  in  an  unaltered  state,  for  a  time 
period  defined  by  local  and  regulatory  requirements. 

•  Stewardship  -  A  clinical  document  is  maintained  by  a  person  or  organization  entrusted 
with  its  care. 

•  Potential  for  authentication  -  A  clinical  document  is  an  assemblage  of  information  that  is 
intended  to  be  legally  authenticated. 

•  Wholeness  -  Authentication  of  a  clinical  document  applies  to  the  whole  and  does  not 
apply  to  portions  of  the  document  without  the  full  context  of  the  document. 

•  Human  readability  -  A  clinical  document  is  human  readable.”3 

• 

The  CDA  specification  does  not  specify  how  to  create  documents  or  how  to  store  them  in 
a  document  management  system.  Similarly,  security,  confidentiality  and  data  integrity 
are  not  part  of  the  CDA  specification.  These  functions  are  outside  the  scope  of  the 
specification  and  are  left  to  individual  implementations. 

“A  CDA  document  is  comprised  of  a  header  and  a  body.  The  header  identifies 
and  classifies  the  document  and  provides  information  on  authentication,  the 
encounter,  the  patient,  and  the  provider.  The  purpose  of  the  CDA  header  is  to 
enable  clinical  document  exchange  across  and  within  institutions;  facilitate 
clinical  document  management;  and  facilitate  compilation  of  an  individual 
patient's  clinical  documents  into  a  lifetime  electronic  patient  record.  The  body 
contains  the  clinical  report,  and  is  conceptually  divided  up  into  body  structures, 
body  entries,  and  external  references.”4 

Application  developers,  like  the  ARL  team,  can  build  CDA  templates  to  create 
specialized  CDA  documents  such  as  “discharge  summary”,  “consultation  note”  or 
“electronic  medical  record”.  Each  template  can  implement  its  own  constraints  for  the 
sections  in  the  document  (section-level  templates)  as  well  as  the  information  recorded 
within  each  section  (entry-level  templates). 


2  HL7  Web  Site,  http://www.hl7.org/library/ 

3  “HL7  Clinical  Document  Architecture,  Release  2”,  San  Antonio  Draft,  January  6,  2003. 

4  “HL7  Clinical  Document  Architecture,  Release  2”,  San  Antonio  Draft,  January  6, 2003. 
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The  XML  CDA  document  is  both  machine  processible  and  human  readable,  however,  the 
human  readable  format  is  valuable  only  to  technical  people.  The  CDA  will  usually  have 
an  XML  stylesheet  applied  to  it  before  it  is  presented  to  medical  personnel  so  that  it 
resembles  a  word  processed  document  or  a  web  page.  The  CDA  has  been  designed  so 
that  a  single  stylesheet  can  be  applied  to  all  CDA  documents. 

Once  created,  it  is  sometimes  necessary  to  modify  or  replace  CDA  documents.  The 
specification  includes  attributes  to  indicate  the  identification  and  version  number  of 
updated  documents. 
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Summary 


The  research  above  reveals  that  there  are  very  inventive  technologies  on  the  horizon  for 
tackling  the  problem  of  efficiently  converting  paper  medical  records  into  electronic  form. 
In  the  near  term,  however,  the  combination  of  keyboard  entry,  voice  recognition, 
handwriting  recognition  and  optical  character  recognition  can  be  selectively  and 
affordably  combined  into  a  realistic  and  practical  solution  for  this  challenge.  No  single 
technology  satisfies  all  the  requirements.  Once  converted,  the  HL7  and  CDA  standards 
are  viable  for  saving  and  transmitting  the  electronic  medical  record. 
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Purpose 


An  affordable  and  streamlined  process  is  needed  to  migrate  the  critical  patient 
information  from  legacy,  paper-based  patient  records  into  an  electronic  format  that  is 
compatible  with  information  technology  that  can  be  successfully  employed  in  the  rural 
healthcare  delivery  system  to  overcome  resource  shortages  and  improve  collaboration 
among  service  providers. 

This  document  summarizes  the  information  physicians  require  to  be  converted  from 
paper-based  electronic  medical  records.  The  specific  task  is: 

“Conduct  a  literature  review,  focus  groups  and  individual  interviews  with  medical 
providers  (physicians  and  nurses)  and  medical  administrators  to  determine  the 
appropriate  content  of  a  patient  record.  The  intent  should  not  be  so  much  as  to 
agree  upon  the  ideal  patient  record  as  to  determine  what  information  is  needed  to 
adequately  represent  a  patient  record  given  its  transition  from  paper  content  to 
electronic  format.” 


Background 

Armstrong  County  Memorial  Hospital  (ACMH)  provided  40  Primary  Care  medical 
records  to  be  converted  from  paper  to  an  electronic  form,  to  the  ARL  team.  The  medical 
records  do  not  have  a  consistent  structure,  order  or  content  and  there  are  several  formats 
for  recording  the  same  information,  such  as  allergies.  All  records  have  handwritten  notes 
with  the  expected  wide  variations  in  legibility.  Many  records  have  ambiguous  entries  in 
form  fields,  such  as  checkboxes,  that  are  easily  resolved  by  looking  at  other  information 
on  the  form. 


Approach 

Private  practice  physicians  and  ACMH  physicians  were  asked  to  supply  their  top  ten 
chart  extractions.  Six  physicians  of  different  specialty  supplied  a  list  of  their  top  ten  chart 
extractions.  From  these  lists,  the  ARL  team  compiled  a  list  to  determine  the  chart 
extractions  that  were  identified  consistently  by  the  physicians  and  the  number  of  times  it 
appeared  in  the  physician’s  lists. 

Once  the  information  was  compiled,  physicians,  hospital  administrators  and  ARL 
personnel  held  a  meeting  to  discuss  the  compiled  information.  It  was  determined  from 
this  meeting  that  the  information  most  frequently  requested  in  their  survey  responses  was 
not  necessarily  their  top  priority.  After  an  hour  of  discussions,  the  following  patient 
information  categories  will  need  to  be  captured  to  create  an  Electronic  Medical  Record 
(EMR): 

•  Demographics 

•  Patient  Problem  History 

•  Family  History 

•  Social  History 
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•  Medications 

•  Allergies 

•  Labs 

•  Radiology 

•  Cardiology 

•  Discharge  Summary 

The  related  information  per  above  category  was  determined  and  an  initial  source  and 
capture  technique  were  determined.  The  categories  and  associated  information  will  be 
described  in  Information  Priorities  section. 

Information  Priorities 


Patient  Information  Categories 

The  following  chart  is  a  summary  of  the  Top  10  Chart  Extractions  from  the  information 
the  physicians  provided. 
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Patient  Information  Categories 

After  meeting  with  the  physicians  and  ACMH  administration,  patient  information 
categories  were  determined  from  the  Top  10  Chart  Extractions.  The  following  sections 
provide  the  description  for  the  different  patient  information  categories  as  well  as  the 
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primary  and  secondary  sources  and  the  primary  and  secondary  techniques  for  capturing 
the  information  in  the  electronic  health  record. 

Demographics 
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Introduction 


Physicians  need  affordable  and  streamlined  process  to  migrate  critical  patient  information 
from  legacy,  paper-based  patient  records  into  an  electronic  format  that  is  compatible  with 
information  technology  that  can  be  successfully  employed  in  the  rural  healthcare  delivery 
system  to  overcome  resource  shortages  and  improve  collaboration  among  service 
providers. 


The  source  documents  are  scanned  into  a  database  as  PDF  documents  and  processed  using 
the  abstraction  tool  (henceforth  ARMSTAR  GUI).  Information  can  also  be  extracted  from 
existing  electronic  databases.  The  abstracted  data  is  then  processed  into  a  CDA  (Clinical 
Document  Architecture)  version  2  document.  CDA  is  a  standard  of  HL7 
ditto  ://www.h!7.orgV  Figure  1  shows  an  overview  of  the  ARMSTAR  system. 


Figure  1.  ARMSTAR  Overview 
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This  document  describes  the  components  of  the  ARMSTAR  Care  Critical  Data  Abstraction 
System,  defines  their  role  as  part  of  the  overall  system,  as  well  as  the  interactions  between 
components.  For  the  purpose  of  this  document,  the  components  are  classified  between 
server  (Care  Critical  Information  Server)  and  client  (Abstract  Station),  although  both 
server  and  client  components  can  be  configured  on  the  same  system  for  standalone  usage. 
Figure  2  shows  the  different  technologies  that  have  been  integrated  during  the  course  of 
this  project.  This  figure  shows  a  Scan/Import  station.  Any  PC  with  access  to  a  high- 
quality  scanner  and  connectivity  to  the  server  could  function  as  a  Scan/Import  Station,  so 
this  part  of  the  architecture  is  not  detailed  in  this  document. 
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Figure  2.  ARMSTAR  Technologies 
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Overview 

The  Care  Critical  Information  Server  has  several  roles.  It  provides  a  centralized  resource 
for  importing  and  maintaining  patient  records  as  they  are  transformed  into  CDA 
documents.  It  contains  the  database  server  that  is  the  persistent  store  for  imported 
documents,  raw  abstracted  data,  and  patient  records  in  the  CDA  format.  It  also  provides 
the  capability  to  serve  patient  records  to  remote  users. 

MySQL  Database 

The  MySQL  database  is  the  persistent  store  for  patient  data.  Table  1  shows  the  tables  and 
fields  of  the  database.  Columns  labeled  in  bold  are  keys.  The  first  column  for  a  particular 
table  is  the  primary  key.  All  tables  use  “patient_id”  as  a  key.  This  makes  it  possible  to 
gather  all  knowledge  of  a  particular  patient  with  a  single  key.  Some  tables  use  “entry_id" 
also.  This  key  serves  to  identify  individual  data  entries  under  a  particular  category  and  link 


Page  35  of  50 


them  to  the  “images”  table.  The  “images”  table  allows  image  data  to  be  associated  with 
any  table  or  entry  in  the  database,  the  same  table.  It  can  store  multiple  images  for  a 
particular  entry.  This  flexibility  is  achieved  by  using  the  “image_id”  and  “tablename” 
columns  in  addition  to  the  standard  keys  used  elsewhere. 

Table  1.  ARMSTAR  Database 


Column 

Data  Type 

patient_id 

System.Int32 

First_name 

System.String 

Lastjname 

System.String 

address_l 

System.String 

address_2 

System.String 

City 

System.String 

State 

System.String 

Zip 

System.String 

home__phone 

System.String 

work_phone 

System.String 

mobile_phone 

System.String 

marital_status 

System.String 

Sex 

System.String 

Race 

System.String 

religion 

System.String 

Dob 

System.String 

Height 

System.String 

weight 

System.String 

patientid 

System.Int32 

policy jiumber 

System.Int32 

group_number 

System.String 

subscriber_name 

System.String 

policy_effective_date 

System.String 

relationship_to_subscriber 

System.String 

Dob_of_subscriber 

System.String 
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Pep 


co_pay 


entryid 


patientjd 


Agent 


Adverse_reaction 


date_reported 


Allergy Jype 


entryid 


patient_id 


Date 


interpretation 


System.String 


System.Int32 


Systemlnt32 


Systemlnt32 


System-String 


System  String 


SystemString 


SystemString 


System.Int32 


Systemlnt32 


SystemString 


SystemString 


entry Jd 


patientjd 


System  Int32 


Systemlnt32 


admission_date 

System.  String 

discharge_date 

SystemString 

reason Jor_admission 

SystemString 

discharge_diagnosis 


services 


Summary jDfJindings 


Drg_data 


entryid 


patientjd 


relationship 


Problem 


comments 


SystemString 


SystemString 


SystemString 


SystemString 


Systemlnt32 


Systemlnt32 


SystemString 


SystemString 


SystemString 


image_id 


patientjd 


tablename 


entry  Jd 


Systemlnt32 


Systemlnt32 


SystemString 


Systemlnt32 
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description 


filename 


thumbnail 


full_image 


entryid 


patientjd 


date 


name 


Age 


comments 


entryid 


patientid 


Date 


Test 


Result 


interpretation 


entryid 


patientid 


name 


SystemString 


SystemString 


SystemDrawing.Bitmap 


SystemDrawing.Bitmap 


System.  Int32 


System.Int32 


System.  String 


System  String 


System.  String 


dosage_quantity 


dosage  Jrequency 


date  started 


date  ended 


Reason 


System  String 


Systemlnt32 


Systemlnt32 


System.  String 


SystemString 


System.  String 


SystemString 


Systemlnt32 


System.Int32 


System.String 


SystemString 


SystemString 


SystemString 


SystemString 


SystemString 


System.Int32 


patientjd 

System.Int32 

Problem 

System.  String 

Icd9_code 

System.  String 

Comments 

System.  String 

onset_date 

System.  String 

Frequency 

System.  String 
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inactive_date 

System.Stdng 

entry_id 

System.  Int32 

patientid 

System.Int32 

Date 

System.String 

Test 

System.  String 

interpretation 

System.  String 

ill  g|f§  .  '  |f  s  ?  if 

entryid 

System.  Int32 

patient_id 

System.Int32 

Alcohol_use 

System.String 

Tobacco_use 

System.  String 

drug_use 

System.  String 

sexual_activity 

System  String 

birth_controlj>rotection 

System.String 

IIS/PHP  Server 

Microsoft’s  IIS  (Internet  Information  Server)  is  used  to  provide  a  web  interface  to  the  Care 
Critical  Information  Server.  PHP  is  used  to  provide  dynamic  access  to  the  database 
resources.  PHP  is  a  popular  language  for  developing  web  applications.  It  allows  rapid 
development  of  web  interfaces  to  SQL  database  systems  such  as  MySQL.  By  using  PHP, 
we  were  able  to  develop  a  rudimentary  interface  for  developing  and  testing  the  CDA 
Generator  while  the  ARMSTAR  client  was  still  in  its  infancy. 

Java  CDA  Generator 

The  Java  CDA  Generator,  when  requested,  retrieves  a  patient’s  data  from  the  MySQL 
database  and  generates  an  XML  document  directly  from  the  database.  This  document  is 
then  processed  by  a  stylesheet  to  produce  a  human-readable  document.  This  document  is 
usually  in  the  form  of  HTML.  The  HTML  document  can  be  viewed  via  the  web  interface 
or  from  the  client.  The  Clinical  Document  Architecture,  Version  2,  leverages  the  rich 
object-oriented  data  model  of  the  HL7  Version  3  standard.  We  chose  to  implement  our 
CDA  Generator  using  Java  technology  because  HL7  is  producing  their  own  reference 
implementation  of  the  HL7  Version  3  standard  in  Java.  The  current  ARMSTAR  Java 
CDA  Generator  does  not  make  use  of  the  HL7  code,  but  the  use  of  Java  here  should  make 
a  potential  future  integration  much  smoother. 
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Abstract  Station 

Overview 

Various  data  collection  methods  were  evaluated  as  the  GUI  was  designed  and  tested. 

Table  2  provides  a  summary  of  the  comparison.  To  provide  an  efficient  environment  for 
data  collection  and  abstraction,  the  following  assumption  was  made: 

The  GUI  will  give  the  user  the  flexibility  to  decide  the  appropriate  tradeoff  between 
the  speed  of  data  collection  and  detail  of  data  abstraction.  A  provider  organization 
may  develop  guidelines  for  collection  and  abstraction,  but  the  application  will  not 
attempt  to  implement  such  guidelines  beyond  the  database  schema. 

There  are  2  motivations  for  making  this  assumption.  First,  programming  the  application 
with  the  knowledge  to  implement  data  collection  guidelines  would  be  exceedingly 
difficult.  Second,  doing  so  would  only  restrict  the  flexibility  of  the  application.  Having 
this  flexibility  means  the  user  will  have  the  ability  to  use  any  data  collection  method  at  any 
point  in  the  application.  It  is  the  user’s  responsibility  to  choose  a  collection  method  which 
is  suitable  to  how  the  data  is  likely  to  be  used  in  the  future.  For  example,  if  medication 
information  is  collected  using  image  capture,  a  future  database  search  for  a  certain  type  of 
medication  would  probably  not  be  able  to  find  the  medication  if  it  was  contained  within 
image  data.  However,  the  data  would  still  display  in  a  human-readable  representation  of 
the  CD  A. 


The  data  collection  methods  are  summarized  in  the  following  table: 
Table  2.  ARMSTAR  Data  Collection  Methods 


reat  for 

anscriptionists. 


ice  for  reading 
ong  hand  written 
ext. 

DK  for  hands  free 
lavigation. 


K  in  tablet  only 
;nvironment. 


.  good 
transcriptionist  can 
probably  move 
faster  with 
"keyboard  and 
ouse. 


Slowest  entry 
method. 


freliminary 

ecommendations 


continue  to  refine.  Need 
o  add  shortcut  keys. 


Continue  to  refine. 
Customer  feedback  will 
lictate  its  future. 


age  capture 


nly  valuable  in  very 
aobile  environment  or  for 
:eyboard  novices. 


Leep  it.  Big  time  saver. 


eep  it.  Good  for  keeping 
listorical  record  of 
elevant  images. _ 
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The  ARMSTAR  GUI  is  divided  into  3  main  panels:  an  explorer  bar  to  the  left,  a  tabbed 
panel  in  the  center,  and  a  data  entry  panel  to  the  right.  Figure  3  is  a  screenshot  of  the 
application. 


Figure  3.  ARMSTAR  GUI 
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Explorer  Bar 

The  explorer  bar  provides  navigation  controls  for  selecting,  importing,  and  submitting 
patient  data.  It  also  contains  the  “tree  view”  of  the  data.  The  top  level  of  the  tree  shows 
the  main  categories  of  data  collection.  These  categories  correspond  to  tables  in  the 
database.  Some  of  these  categories  can  contain  child  nodes  known  as  entries.  The  entries 
correspond  to  database  rows  distinguished  by  the  “entryjd”  key.  New  entries  can  be 
added  by  right-clicking  on  the  tree  view. 

Tab  Panel 

The  tab  panel  allows  the  user  to  switch  between  the  “Scan”  tab  and  the  “CD A”  tab.  The 
“Scan”  tab  uses  the  Adobe  Acrobat  ActiveX  control  to  display  scanned  documents  which 
have  been  imported  into  the  database.  This  allows  the  user  to  navigate  imported  paper 
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documents  and  use  them  as  a  source  for  image  capture  or  OCR.  The  “CD A”  tab  allows  the 
user  to  view  output  directly  from  the  CDA  generator.  This  allows  the  user  to  verify  the 
final  disposition  of  the  data. 

Voice  Recognition  and  Medical  Dictionary 

Scansoft’s  Dragon  Naturally  Speaking  7  Medical  Solutions  system  is  integrated  into  the 
Abstract  Station  as  an  ActiveX  control.  This  system  provides  voice  commanding  and 
navigation  of  the  GUI  as  well  as  voice-based  data  entry.  Data  entry  capability  is 
augmented  by  the  use  of  an  extensive  medical  dictionary  which  gives  the  system  a  very 
high  level  of  accuracy  when  recognizing  medical  terminology.  The  ARMSTAR  client 
dynamically  configures  Naturally  Speaking  with  voice  commands.  This  allows  the  user 
navigate  all  data  entry  screens  and  fields  hands-free.  Naturally  Speaking  includes  a 
sophisticated  system  for  editing  text.  A  key  feature  is  the  ability  to  select  erroneous  words 
and  replace  them  from  a  drop-down  menu  of  likely  substitutions. 

For  best  results,  the  user  needs  to  perform  training  with  the  Naturally  Speaking  product 
before  using  the  ARMSTAR  system.  During  training,  Naturally  Speaking  does  an  audio 
quality  test  to  confirm  that  the  audio  input  device  is  capable  of  capturing  sufficient  quality 
audio.  The  program  includes  texts  with  varying  difficulty  levels  for  the  training  process. 
The  user  selects  a  passage  from  those  provided  and  reads  the  text  in  short  blocks,  a  task 
which  consumes  about  1 5  minutes.  The  user  may  then  provide  sample  texts  such  as 
emails  or  other  documents  for  the  system  to  become  acclimated  to  a  particular  style  of 
writing.  These  additional  texts  can  also  be  used  for  further  voice  training.  Depending  on 
the  speed  of  the  computer  the  entire  process  may  take  between  25  and  45  minutes. 

Optical  Character  Recognition 

The  ARMSTAR  GUI  also  contains  an  OCR  (Optical  Character  Recognition)  component. 
The  tool  is  a  part  of  ISI  Toolbox  from  Image  Solutions,  Inc.  It  works  as  a  plug-in  for  the 
Acrobat  ActiveX  control.  The  OCR  component  allows  typed  text  which  was  scanned  into 
the  source  document  to  be  quickly  converted  into  machine-readable  text.  As  opposed  to 
scanned  data,  which  is  graphical,  machine-readable  text  can  be  searched  or  processed  by 
computers.  This  will  allow  better  abstraction  of  the  data. 

4.  Conclusion 

While  it  is  obviously  desirable  that  all  of  the  information  in  a  patient’s  file  be  quickly 
stored  in  an  easily  searchable  electronic  format,  this  is  an  unrealistic  goal  given  the 
constraints  of  designing  an  efficient,  low-cost  system.  Instead,  the  ARMSTAR  system 
provides  a  flexible  framework  with  several  options  for  collection  and  abstraction.  Inherent 
in  this  design  is  the  assumption  that  the  user  will  be  able  to  determine  the  appropriate 
balance  between  collection  speed  and  detail  of  abstraction.  Fortunately,  as  a  target  data 
format,  the  CDA  specification  was  designed  with  the  flexibility  to  make  this  system 
possible.  Plus,  it  allows  the  data  to  be  imported  as  an  electronic  record  into  other  Health 
Information  Systems. 
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WhatisPACS? 


The  acronym  “PACS”  stands  for  Picture  Archive  Communication  System.  [Historically], 
the  pictures,  or  images,  taken  in  a  radiology  department  are  put  on  film.  State  and  Federal 
laws  require  that  these  films  be  kept  for  a  minimum  of  five  years  unless  it  is  a  pediatric  or 
mammography  study.  Pediatrics  must  be  kept  for  five  years  after  the  patient  turns  '18,  and 
mammography  must  be  stored  for  15  years.  These  laws  create  a  necessity  for  massive 
storage  space.  In  order  for  a  referring  physician  to  view  images,  they  must  either  check  out 
original  films  or  visit  the  film  library.  Film  presents  other  difficulties  as  well,  including: 
material  expense,  long  turnaround  time,  damaged  or  lost  studies,  and  an  inability  to  adapt 
to  the  changing  technological  environment.  PACS  eliminates  the  need  for  massive  storage 
space  and  the  difficulties  inherent  in  film  usage. 

Currently,  within  [ACMH]  radiology  services,  computers  are  used  to  create  images  in  CT, 
MRI,  ultrasound,  nuclear  medicine  and  digital  radiography.  These  modalities  convert  a 
digital  image  to  film.  PACS  utilizes  computer  technology  to  capture,  store,  manipulate 
and  send  digital  images  instead  of  using  film.  For  digital  modalities,  PACS  simply 
captures  the  image  from  the  devices’s  computer  and  stores  it  in  the  PACS  computer, 
instead  of  converting  it  to  film.  The  digital  images  are  then  stored  in  a  master  archive 
where  the  images  are  accessible  for  viewing.  The  images  may  be  viewed  at  any  designated 
review  station  connected  to  the  PACS  or  hospital  network.  The  images  may  be  transferred 
outside  the  hospital  using  telephone  communications  via  POTS,  ISDN,  T1  or  T3  using 
Web  technology. 

For  the  non-digital  modalities,  such  as  x-ray  systems,  or  x-ray  and  fluoroscopy  systems 
(analog  modalities),  the  images  need  to  be  converted  to  a  digital  format.  This  can  be 
accomplished  using  three  different  methods.  The  first,  and  most  popular  method  being 
used  today  is  Computed  Radiography  (CR).  This  method  uses  phosphorus  plates  that  look 
like  regular  film  cassettes  to  capture  digital  information  by  exposing  the  phosphorus  to 
radiation,  then  using  a  computer  to  create  the  image  using  that  digital  information. 

Efficiency  Gains 

PACS  will  not  only  achieve  . . .  cost  savings  ...  it  will  drastically  improve  the  efficiency  of 
the  radiology  department. 

Eliot  L.  Siegel,  MD  describes  the  effects  of  PACS  on  Boston  VA  Medical  Center  in  “The 
Benefits  of  Filmless  Radiology”  He  cites  a  study  performed  at  the  Boston  VA  Medical 
Center  regarding  the  effect  of  PACS  on  their  Radiology  department,  specifically  on  CT 
technicians.  What  they  found  was  that  the  time  for  a  technologist  to  complete  a  CT  exam 
was  decreased  by  50%  to  60%.  The  time  for  the  radiologist  to  read  the  CT  exam  was 
decreased  by  approximately  15%  with  an  overall  decrease  of  8%-12%  noted.  The  results 
discussed  by  Dr.  Siegel  are  not  a-typical. 

In  addition  to  decreased  time  to  read  the  exam,  most  facilities  see  a  significant  reduction  in 
turnaround  time  for  images.  This  can  be  especially  important  in  STAT  cases.  Instead  of 
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waiting  for  the  traditional  filmed  exam  to  follow  its  natural  course  from  the  modality  to  the 
radiologist  to  the  primary  physician  or  specialist,  PACS  allows  the  images  to  be  available 
immediately  on  the  hospital  network.  At  Boston  VA  Medical  Center,  Dr.  Siegel  notes  that 
a  voice  report  is  available  in  5  to  10  minutes  while  a  transcribed  report  is  posted  to  the 
hospital  information  system  (HIS)  in  one  to  two  hours.  This  increased  efficiency  has  been 
credited  with  reducing  the  length  of  time  a  patient  stays  in  the  hospital  or  emergency  room, 
improving  the  quality  of  patient  care,  and  increasing  physician  referrals. 

Another  issue  often  experienced  in  radiology  departments  is  that  of  lost  or  rejected  studies, 
resulting  in  lost  revenue,  reduction  in  patient  satisfaction,  increase  in  turnaround  time  to 
the  referring  physician  and  many  other  concerns.  Lost  films  are  inherent  to  hard  copy  due 
to  the  fact  that  they  can  only  be  in  one  place  at  a  time.  PACS  solves  that  issue  by  allowing 
soft  copy  distribution  to  several  places  at  a  time.  Additionally,  PACS  stores  the  image  in  a 
digital  archive.  Boston  VA  Medical  Center  sites  a  7.9%  decrease  in  the  incidence  of  lost 
film  since  PACS  implementation. 

Rejected  studies  are  also  reduced  with  PACS.  The  incidence  of  poor  image  capture 
technique  is  significantly  reduced.  This  is  due  to  the  image  correction  tools  available  in 
PACS,  as  well  as  the  ability  to  view  the  image  on  computer  screens  prior  to  printing  the 
film.  Image  rejection  rates  were  reduced  from  5%  to  0.8%  at  Boston  VA  Medical  Center 
with  their  PACS  implementation. 

Another  benefit  of  PACS  is  the  ability  to  sustain  a  sudden  growth  without  a  decrease  in 
quality  of  care  or  an  increase  in  staffing  levels.  “Early  Adopter  Adapts”  discusses  the 
challenges  faced  by  Boston  VA  Hospital  when  they  initially  adopted  PACS,  and  when  they 
merged  with  two  other  Massachusetts  VA  hospitals  and  assorted  clinics  to  form  the  VA 
Boston  Healthcare  System.  The  merger  required  that  Boston  VA  upgrade  to  faster 
computers  due  to  the  increase  in  exam  volumes  and  the  article  quotes  M.  Elon  Gale,  MD 
of  Boston  VA  Hospital  as  saying: 

Before  PACS,  all  of  these  sites  taken  as  a  whole  employed  about  25  radiologists ; 
now  the  number  is  around  15.  In  part,  we  had  25  because  our  operating  budgets 
were  more  generous  in  those  days  and  we  could  afford  to  staff  like  that.  But 
mainly,  we  had  25  because  we  needed  25.  Now  we  are  able  to  accomplish  an 
equivalent  workload  thanks  to  PACS  and  its  potent  economies  of  scale. 

Cape  Fear  Valley  Medical  Center  performed  a  study  regarding  the  length  of  stay  pre-  and 
post-PACS.  ‘TACS  Credited  With  Cutting  Length  of  Stay  By  Over  A  Day  in  3 ICU 
Units”  describes  the  results  of  the  study.  Although  there  was  no  proof  that  PACS  was  the 
cause  of  the  length  of  stay  reduction,  staff  could  not  point  out  to  any  other  explanation. 

The  rapid  turnaround  of  exams  allowed  for  better  assessment  of  patients,  making  a 
difference  in  the  outcome  of  ICU  patients. 
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Position  Paper  Regarding  Protection  of  Personal  Health  Information 


Prepared  bv 

Dianne  Emminger 

Vice  President  Information  Services 

Armstrong  County  Memorial  Hospital 
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Definitions: 


Access  Access  to  patient  information  is  addressed  in  several  hospital 
policies  and  medical  staff  rules  and  regulations.  In  summary, 
those  policies  dictate  that  confidential  patient  information  be  made 
accessible  only  to  those  employees/staff  members  who  are 
involved  in  the  care  of  the  patient,  the  management  of  the 
records,  the  billing  for  patient  services,  and  to  others  on  a  need- 
to-know  basis  (i.e.  quality  review  or  resource  utilization.) 

Security  ACMH  utilizes  physical  security  combined  with  several  layers  of 
logical  security  systems  to  restrict  access  to  confidential 
information  that  is  stored  electronically. 


Network  security: 

The  network  is  segmented  into  several  smaller  networks,  which  serve  to  separate 
the  types  of  information  being  stored.  For  example,  patient  information  resides  on 
a  different  segment  than  Internet  or  archives  of  policies  and  procedures.  One  of 
the  computer  systems  on  the  network,  the  access  server,  is  programmed  to  make 
the  determination  of  which  users  can  access  servers  on  any  segment  of  the 
network. 

•  Computers  on  the  backbone  are  given  special  addresses  to  gain 
access. 

•  Dial-up  users  located  in  off-campus  physician’s  offices  utilize  a  process 
wherein  they  dial  into  the  system  and  the  system  calls  them  back  - 
verifying  the  location  of  the  user. 

•  Remote  users  that  desire  access  to  the  network  via  high-speed  Internet 
connections  utilize  a  combination  of  a  virtual  private  network  (VPN), 
data  encryption,  specific  addressing  schemes,  and  secure  id  devices 
(key  fobs.) 

•  Network-to-network  connectivity  is  accomplished  using  intelligent 
routers. 

In  all  of  the  above  access  methods,  the  user  still  needs  a  password.  Internet 
“hackers”  are  blocked  from  the  network  by  a  firewall  and  entry  attempts  are  logged 
and  reviewed  by  our  network  administrator. 


Application  Security: 

Once  the  user  has  cleared  the  network  access  systems  and  has  entered  our 
network  he  needs  yet  another  password  to  access  the  specific  computer  hosting 
the  application.  Within  the  application  itself,  our  systems  restrict  the  specific 


Page  47  of  50 


information  the  user  may  see — i.e.,  patient  demographic  information,  clinical 
information,  or  business  information.  The  following  specifications  have  been 
developed  for  the  acquisition  of  new  systems. 

User  defined  passwords 

Forced  password  changes  within  set  periods  of  time 
Passwords  must  be  a  certain  length 

Systems  must  deny  access  after  a  defined  number  of  incorrect  attempts 
Systems  must  automatically  log  back  or  off  after  a  defined  period  of  time 
and  require  a  password  for  re-entry 

Systems  must  log  all  access  to  confidential  information,  including  read  only, 
identifying  the  user. 

Data  encryption  on  the  server 


Mitigation  of  Risks: 

People  can  make  mistakes  -  wrong  patient  -  wrong  information.  Programs  may 
contain  “bugs”  and  fail  to  operate  as  specified.  Downtime  interrupts  the  constant 
flow  of  information  collection  and  recovery  systems  may  fail  to  identify  missing 
information. 

These  risks  however  are  mitigated  by  some  of  the  features  modern  information 
technology  can  provide.  Well-programmed  computer  applications  actually  provide 
tools  to  identify  errors  and  improve  information  integrity.  All  technology  purchased 
with  federal  funds  and  used  to  process  live  data  is  purchased  from  reputable 
companies  with  proven  track  records.  We  have  engineered  redundancy  into  our 
systems  so  that  there  is  no  single  point  of  failure.  Disaster  recovery  plans  have 
been  created  to  provide  mechanisms  to  ensure  that  all  data  collected  during  down 
times  are  entered  into  the  system.  Backup  tapes  are  kept  in  a  secure  location 
remote  to  the  main  processing  site.  “Hot-site”  and  mobile  back-up  processing 
capacity  is  assured  through  a  contract  with  Sunguard  Recovery  Services  and 
funded  by  ACMH. 


Transmission  Modes: 

Dial-up  access  over  POTS:  network  access  is  controlled  by  a  combination  of 
caller-ID  and  passwords.  Access  to  data  is  controlled  through  authentication  to 
the  Citrix  Server  and  authentication  to  the  Meditech  EMR.  When  Caller-ID  is  not 
available,  the  user  will  be  identified  via  user  name  and  Secure  ID  password. 

Internet  access  using  proprietary  VPN  and  Secure  ID  software:  the  user  is 
identified  by:  VPN  Client  Secure,  user  name,  and  Secure  ID  password.  Network 
and  EMR  authentication  are  controlled  through  the  Citrix  application  server  and 
the  Meditech  Server.  Dedicated  high-speed  connection:  access  is  controlled 
through  the  Citrix  application  server  and  the  Meditech  EMR  server. 
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Armstrong  County  Memorial  Hospital 
Armstar  Network  Schematic 

Prepared  by  Thomas  Admason,  Director  of  Network  Technology 
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